home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9607 / 000007_owner-urn-ietf _Sat Jul 13 00:37:37 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA22126 for urn-ietf-out; Sat, 13 Jul 1996 00:37:37 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA22121 for <urn-ietf@services.bunyip.com>; Sat, 13 Jul 1996 00:37:34 -0400
  3. Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA14476  (mail destined for urn-ietf@services.bunyip.com); Sat, 13 Jul 96 00:37:30 -0400
  5. Received: from void.ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id XAA25024; Fri, 12 Jul 1996 23:37:30 -0500
  6. Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
  7.     id AA25802; Fri, 12 Jul 96 23:34:20 CDT
  8. Date: Fri, 12 Jul 96 23:34:20 CDT
  9. From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
  10. Message-Id: <9607130434.AA25802@void.ncsa.uiuc.edu>
  11. To: jch@jch.com (YON - Jan C. Hardenbergh)
  12. Cc: urn-ietf@bunyip.com, mitra@earth.path.net, rikk@best.com
  13. Subject: [URN] What about getting stuff off of CDs?
  14. In-Reply-To: <199607122329.TAA00478@perseus.ultra.net>
  15. References: <199607122329.TAA00478@perseus.ultra.net>
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. jch@jch.com writes:
  22.  > I want to use URNs to get stuff off of CDs, with the browser knowing
  23.  > how to map the URN to the right mount point (some level of indirection).
  24.  
  25. URLs can be used in this way too.  In general, any URIs can be
  26. resolved any way the users configure their browsers to do the
  27. resolution.
  28.  
  29.  > The idea is to explicitly give the browser permission to substitute
  30.  > a matching <NSS> without checking with a registration authority.
  31.  > The CD is a mirror of some sort, and we want a Namespace ID + Authority
  32.  > to grants the browser the right to use local data. This implies trust;
  33.  > speed is more important than document integrity.
  34.  > 
  35.  > Is this just wrong?
  36.  
  37. There is nothing wrong with this, but I am wondering who you think
  38. needs to be trusted.  The user needs to trust that the CD they are
  39. using in the resolution of some URIs is not going to be dishonest.
  40. The naming authority has no choice in the matter.
  41.  
  42. If there is a strong lack of trust, then users should be using URIs
  43. with built-in or associated digital signatures.  But this is true
  44. whether the data comes from a CD or the net, maybe moreso for the
  45. latter.
  46.  
  47.  > Would "URN:x-vrml:<library name>:<NSS>" be obscene? Truly chastised forever?
  48.  
  49. The first two fields up to the second colon fit the generic syntax
  50. that has been agreed on by URN developers.  (I argue that the "URN:"
  51. prefix is meaningless, but otherwise harmless.) Everything else is
  52. opaque and is processed in a way that is dependent on the second
  53. field, the (sub-)scheme name. 
  54.  
  55. The "x-" prefix on the scheme name seems pretty pointless, especially if
  56. this is to be a URN that never changes.  
  57.  
  58. --
  59. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  60. National Center for Supercomputing Applications
  61. http://union.ncsa.uiuc.edu/~liberte/